The boot sector is a feature which is supposed to launch software off the disk as soon as the computer is powered up or reset. However, using this handy feature for your own purposes has been very difficult. The autoboot tool consists of several modules which makes creation and manipulation of boot sectors quick and easy. Please note that using THE SERVANT, a boot sector may be created and executed on a disk drive of any device number.
SPECIAL NOTE to 1581 users: Using the Autoboot Tool, the root directory will be automatically selected. A boot sector cannot exist under a subdirectory.
ANALYZE BOOT SECTOR:
This feature will decode the boot sector and display its results on the screen. First, it indicates if a boot sector is present, if the boot sector is occupied by a file, or if a "killed" boot sector is present. If a boot sector exist, you'll be warned if it is not protected from overwriting (not protected by BAM). In that case use the Protect Sector(s) feature to protect it if desired. If a boot sector or killed boot sector exists, the following information is provided:
1) Additional boot sectors info. The C128 boot system includes an option to read additional blocks off the disk as part of the boot area. These extra sectors starts at track 1, sector 1, and continue onward from there. A total of 255 extra boot sectors can be specified, making the boot area use several whole tracks. The C128 boot feature makes it possible to place these extra blocks anywhere in the computer's memory. How many extra blocks to be loaded, the address and memory bank where they are placed are displayed.
2) Load PRG file: A file name can be specified in the boot sector, and if present, a PRG file of that name is loaded into bank 0 RAM. The load address is determined by the load address of the program itself. The file name (if any) will be displayed along with the load address. The load address must be sought in the file itself, and if the file can't be read, a DOS error message is displayed instead of the load address.
3) ML code start: The boot sector must contain some ML code to determine what the boot sector is supposed to do. It may be a simple JMP instruction (similar to BASIC SYS), or an elaborate ML program. The start address of the ML code is not fixed; it is determined by the length of the boot message (see below) and file name (above). The start address is displayed as an offset from the start of the boot buffer in the computer's memory. The boot buffer is at address 2816 ($0b00) in bank 0. To calculate the real start address of the ML code, add this number to the offset value.
4) Boot message: An optional message can be displayed when a boot is performed (BOOT xxxx ...). Often, the name of the program to be booted is displayed, but the message may contain just about anything. The message may contain control codes which is (by the boot sector analyzer) displayed as RVS characters.
5) Command line: Unlike the other information on the analyzer screen, this is not an inherent feature of C128 boot sectors. Rather, by using a small piece of ML code, it is possible to execute a BASIC command line. THE SERVANTs Autoboot Tool contains a provision for creating a command line of your own fancy. Since this is the kind of boot sectors you are probably most often going to create yourself, the BASIC command line (if found) is included here. Incidentally, the same method is used by the "autoboot maker" included on the Test/Demo disk supplied with Commodore disk drives.
Hit any key to return to the Autoboot Tool menu.
DUMP SECTOR:
Displays the contents of track 1 sector 0 as ASCII characters, regardless if it contains a boot sector or not. Control characters are displayed as RVS codes. A boot sector has the letters "cbm" as the three first characters. The Dump feature might be useful for revealing things about a boot sector that would otherwise be difficult to disclose. Also, if the boot sector is blocked by a program, you might be able to identify the program which causes the interference.
Hit any key to return to the Autoboot Tool menu.
MAKE BOOT SECTOR:
The objective here is to create a direct mode BASIC program line to be executed upon booting. All immediate mode BASIC commands can be used, and the possibilities are limited by imagination and the size of the boot sector.
Upon selection of Create from the Autoboot Tool menu, you're warned if a boot sector is already present on the disk, or if the boot sector is taken by a program or other data. If you wish to preserve an original boot sector, please use the Boot To File feature first.
Entering the boot message:
Optionally, you can enter a message to be displayed upon boot (BOOTING xxxx ...). There are a total of 239 characters available for the boot message and command line. Every character of the boot message will steal space from the command line. Just press RETURN without entering anything if you don't want a boot message.
Please note that you are not limited to plain text; control characters may also be used. Please refer to Appendix F for an overview of the control characters and how they are entered. Also please note that your computer in most cases will be in uppercase/graphics mode (alias "cursor up" mode) when the boot message is displayed. Text entered as lowercase will appear as uppercase, and uppercase characters will appear as graphic symbols. You may circumvent this by entering a RVS n as the first character. This will put the computer into lowercase mode (also called "cursor down" mode) when the boot sector is executed.
PLEASE NOTE: NEVER use a RVS @ in your boot sectors. A RVS @ will yield an ASCII code of zero which will effectively terminate the string or command line. Malfunction will be inevitable.
Entering the command line:
This is just like entering a command line in the BASIC immediate mode. Several commands can be used, separated by colons. Loops can be constructed using FOR-NEXT or DO-LOOP/EXIT. Decisions can me made using IF/THEN/ELSE. Please note that you are not restricted to the 160 character limit allowed by the BASIC screen editor. 239 characters is available, minus the length of the boot message (if any). You may use abbreviated BASIC commands if necessary. Of course, the BASIC commands you are going to use most often is BOOT "filename" BLOAD "filename", SYS and RUN "filename".
It is important to use good sense when constructing a command line. Remember that you are limited to BASIC commands legal in immediate mode. This means that INPUT, INPUT#, GET and GET# are out. READ/DATA, GOTO and GOSUB won't work because the command line don't contain line numbers.
Also be careful when using IF-THEN. The command line after the THEN statement will be executed ONLY if the criteria set in the IF statement is true. Let's say that you want to set fast mode if the computer is booted with the 80 column screen active and then run a program. You might try this:
if rgr (0)=5 then fast:run "program"
This will seem to work perfectly in 80 columns, but the program won't be run in 40 columns, why? The commands after THEN will be executed only if the conditions in the IF statements is true. The line below will cure the problem:
if rgr (0)=5 then fast:run "program":else run "program"
You must tell the computer that you want to run the program whether or not the 80 column screen is active. Again, please note that any commands following a ELSE statement will be executed ONLY of the conditions in the IF statement is FALSE. This means that if several commands is to be executed in either case after an IF-THEN command, they must all be included twice; once after the THEN command, and once after the ELSE command. Of course, you may consider writing a normal BASIC program which is run by a simple run "filename" command in the boot sector.
Control codes may be entered as part of the command line, but only inside quotes. Control characters outside quotes will invoke a SYNTAX ERROR. You may notice that typing a quote character won't invoke "quote mode". Rather, if you want to include cursor control, insert, delete, home, clear or return codes, hold down ALT and press the appropriate key. Also please read Appendix E.
When the command line is entered, press RETURN to write your boot sector to disk. Before doing so however, the computer will ask you if its OK to proceed.
Tricks and tips:
You may find it very useful to be able to boot a program from any disk drive. PEEKing address 186 will enable you to do so. When the boot sector is executed, this location will hold the device number used. For example running a BASIC program from any disk drive is done like this:
run "program",u(peek(186))
Please note the use of parentheses. The PEEK command must be enclosed in parentheses for the U specifier to work.
All software might not be able to run off any other disk drive than device 8. To circumvent this sloppy programming practice, you may simply change or swap device numbers. Please refer to your disk drive manual for the command sequence needed. Swapping device numbers, say between device numbers 8 and 9 is done by temporarily setting device 9 to, say, 30, changing device 8 to 9, and then changing the disk drive now using device number 30 to 8.
EDIT COMMAND LINE:
You may want to edit a command line boot sector for debugging purposes or other reasons. The boot sector will be read off the disk and a check is made to establish if a valid boot sector really exist and that it contains a command line. If everything is found to be OK, editing the command line is just like creating it for the fist time. Please refer to the section about creation of a boot sector above. The boot message cannot be edited.
RUN/64 BOOT SECTOR:
This selection will create a boot sector which will load a 64 mode program into computer memory, switch to 64 mode, and run it. If you have a 1571 or 1581 disk drive, the 128 burst load will be active, and will load your program many times faster than in 64 mode. The program to be loaded must be a BASIC program or a ML program which is started with a RUN command.
The boot sector will work with drives of any device number. However, the program you load might not me able to do this.
Please note that the boot sector can't safely handle programs bigger than 153 blocks. However, it is worth trying bigger programs, as they may very well work, especially programs of up to 201 blocks. The boot sector can't handle large program as well as the Main Menu C64 options because of memory constraints. Some RAM under the 64 mode ROMs and I/O is corrupted during setup of the 64 mode.
You will be warned if a boot sector is already present on the disk, or if the boot sector is taken by a program or other data.
Besides entering the file name to be loaded, you are asked if you want to reset the 1571 drive. Resetting the 1571 will switch it to 1541 mode which may me necessary to retain compatibility with the software you are using. If you want to enjoy the double sided mode on the 1571 in 64 mode, select NOT to reset the drive. If you have JiffyDos installed in your system, you should reset the drive in any case, since JiffyDos will be active only if the drive is operating in 1541 mode, while still being able to use double sided disks. If you elect to reset the 1571 and the disk is later booted from another drive type, the error light will flash. However, this is without harmful side-effects.
You will be asked if it is OK to proceed, and the boot sector will then be written to disk.
LOAD "",x,1/64 BOOT:
This selection will create a boot sector that switches the computer to 64 mode, and then performs a load command similar to LOAD "program",8,1. You are not required to use device 8 however, the boot sector will work with all device numbers. The software you are using might not be able to work with such variety of device numbers though. The boot sector can handle programs of up to 201 blocks.
You will be warned if a boot sector is already present on the disk, or if the boot sector is taken by a program or other data.
You will be asked to enter a file name to be loaded by the boot sector code. Optionally, you may also enter a command line of up to 12 characters to be executed after the program has been loaded. Typically, you would use RUN or SYS to start the program. Please note that you don't have to add a return character to the command, the boot sector will execute the command line automatically. If the program is auto-running, meaning that it runs by itself without the need for a RUN or SYS call, press RETURN without entering anything.
You'll also be asked if you want to reset the 1571 drive. Resetting the 1571 will switch it to 1541 mode which may me necessary to retain compatibility with the software you are using. If you want to enjoy the double sided mode on the 1571 in 64 mode, select NOT to reset the drive. If you have JiffyDos installed in your system, you should reset the drive in any case, since JiffyDos will be active only if the drive is operating in 1541 mode, while still being able to use double sided disks. If you elect to reset the 1571 and the disk is later booted from another drive type, it won't produce any side-effects.
You will be asked if it is OK to proceed, and the boot sector will then be written to disk.
BOOT TO FILE:
This feature reads the boot sector off a disk and saves it as a PRG file. It might be useful to use the PRG file as a backup copy of the boot sector, especially if you want to replace the original boot sector. Please note that only track 0, sector 1 will be saved. Multisector boot areas can't be saved by this utility. If in doubt, please use the Analyze Boot Sector option to see if additional boot sectors are present.
The file created by this utility will be fully executable. That is, rather than booting the disk, you may now boot the PRG file:
bank 15:boot "bootfile"
Sometimes, this approach won't work. Please analyze the boot sector you are going to convert and see if a PRG file is loaded by the boot sector. To make the bootfile work is such cases, use the following command syntax:
bload "prgfile",b0:bank 15:boot"bootfile"
The above commands may easily be used as part of the command line in a custom boot sector created by the Create utility. For example, you may want to send commands to a printer interface or change disk device numbers before booting your software. Please note that a bootfile will overwrite the boot sector in the computer's memory when executed. It is therefore not possible for a custom boot sector to load or boot a bootfile and then return for further BASIC commands. This condition will invoke a SYNTAX ERROR, or could even crash the system. The execution of the bootfile should be executed LAST in a custom boot sector command line.
The transfer process begins by reading the boot sector off the disk in the drive. You'll then be prompted for a file name, then the target disk, a disk where to store the resulting file. The target disk must be put into the same drive that was used to read the boot sector.
FILE TO BOOT:
To do the reverse of the above, use this utility. A PRG file is read from disk and its contents is placed in the boot sector. The combination of the boot transfer utilities may be used for archival purposes or for transferring boot sectors between dissimilar drive types. The utility can't handle multisector boot areas, files larger than 256 bytes is truncated.
This utility may equally well be used to enable a boot sector entirely of your own design, where you yourself have written the ML code. A PRG file to become a boot sector must have the following structure:
1) 7 zero bytes. Actually, the three first bytes should contain the ASCII characters "cbm", but these are automatically provided by the transfer utility. You may substitute the three first bytes with a JMP instruction to the start of the ML code for debugging purposes. Incidentally, this is what the Transfer Boot To File utility does.
2) Optional boot message (BOOT xxxx ....). All CBM ASCII characters can be used and the length of the string is limited only by the size of the boot sector.
3) One zero byte (regardless if you include a boot message or not).
4) Optional PRG file to load. If you provide a file name at this point it will be loaded into bank 0 memory (similar to BLOAD "file",b0), but it will NOT be called. Any call address must be provided in the ML code (see below).
5) One zero byte (regardless if you provide a file name or not).
6) ML code. This is normal 6502 ML code.
The exact start of the ML code will be determined by the length of the boot message and/or file name, if any. In its simplest form, a boot sector may contain 9 zero bytes (no boot message or file name) and the ML code must then start at the 10th byte. Any use of boot message and/or file name will force the start of the ML code upwards. As the computer's boot buffer starts at 2816 ($0b00), the actual entry point of the ML code can be calculated using the following formula:
2816+9+length of boot message+length of file name
The transfer process is initiated by a prompt for a file name and the file will be read off the disk. You'll the be asked for the target disk, the disk where to put the boot sector. You'll be warned if the target disk already has a valid boot sector or if the boot sector is occupied by a file. Then, the boot sector is saved to disk.
COPY BOOT SECTOR:
You may easily copy a boot sector from one disk to another. Please note that only track 1, sector 0 will be transferred. Multisector boot areas cannot be transferred by this routine.
The original boot sector is read off the disk and you'll be prompted for the target disk, the disk where to save the boot sector. You'll be warned if the target disk already has a valid boot sector or if the boot sector is occupied by a file. Then, the boot sector is saved to disk.
KILL AUTOBOOT:
You may want to remove the boot feature from a disk, and this selection will enable you to do so. Actually, this utility isn't very radical, the "cbm" boot sector identifier is changed to "kbm", and the boot sector is marked as free in the BAM. It may be a good idea to transfer the boot sector to a file before killing it.
You'll be asked if it is OK to commence the action to be performed. Then, the boot sector will be disabled. You'll be notified if a boot sector don't exist on the disk, and no changes will then be made.
UN-KILL AUTOBOOT:
If you have killed a boot sector, either deliberately or by accident, it may be re-enabled with this feature. Since the Kill feature marks the boot sector as free in the BAM, the boot sector might easily be overwritten by a file saved to disk. It is therefore feasible to un-kill a boot sector as soon as possible.
The disk is checked to see if it contains a recoverable boot sector, and you're asked if it is OK to proceed. The boot sector is then resurrected.
PROTECT SECTOR(S)
For a boot sector to be safe, it must be protected by the Block Availability Map (BAM). Although the DOS commands validate will protect the boot sector, the BASIC COLLECT command and other ways of validating the disk will de-protect it again. To make things right, the Autoboot Tool protect command will re-protect the boot sector(s) without validating the whole disk. Please note that multisector boot areas WILL be protected by this utility.
